Skip to main content
This page documents the org-level role matrix. For the separate workspace-level roles (Owner, Facilitator, Participant), see Workspace roles and permissions.
Organizations and workspaces each have their own Owner role. This page covers organization roles, where Owner is the all-access role. A workspace Owner only governs a single workspace — always read “Owner” with its scope in mind.

​
Roles in your org

A Playlab organization has five roles, listed from most to least access:
The organization role dropdown listing five roles: Owner — can manage members and edit any apps, collections, or workspaces within the organization; Creator — can create apps, collections, and workspaces within the organization; Editor — can create apps and collections within the organization; Viewer — can view and use apps within the organization; and Workspace-only — can only see apps in workspaces they are added to and cannot see the apps tab.

The organization-level roles, shown in the member role picker.

Owner The all-access role. Owners can manage members and edit any apps, collections, or workspaces in the organization — invite people, change roles, configure org settings, and see all activity and flagged messages. Most orgs keep this to two to four people. Creator Can create apps, collections, and workspaces within the organization. A good fit for teacher-leads and active builders who need to spin up their own spaces, without administering the whole org. Editor Can create apps and collections within the organization (but not workspaces). For contributors who build and share apps without running classes. Viewer Can view and use apps within the organization. Read-and-use access for participants, observers, or coaches. Workspace-only Can only see apps in the workspaces they’ve been added to — they don’t get the org-wide Apps tab. The most scoped role, ideal for students and members who should only ever work inside their assigned classes.

​
How to change a member’s role

1

Go to the org Members tab

From the org dashboard, click Members. You see all org members with their current roles.
2

Find the member

Search by name or scroll. Click the member to open their detail panel.
3

Change the role

The role dropdown shows the five roles. Pick the new role.
4

Confirm

The change applies immediately. The member’s permissions update on their next page load.

​
Permission inheritance

Permissions cascade from org to workspace to app. Each level grants access to what’s inside it, with one exception (apps follow their owner, not the workspace). Org Owner has read access to every workspace and every app in the org, regardless of explicit invites. This is the trust and safety layer. Workspace Owner and Facilitator have full access inside the workspace they run. They do not get org-wide access from a workspace role alone. Workspace Participant has access to the workspace they were invited to. App-level permissions are set per app. App owner keeps control of their app, even if their workspace role changes. Removing a person from a workspace does not transfer their apps. Apps follow their owner. For trust and safety: an organization Owner always has visibility into every app, workspace, and conversation in the org, including private apps. This is documented in App privacy and visibility.

​
Best practices

Useful patterns for organization Owners: Keep the Owner count small. Two to four for most orgs. Each Owner can do everything; large numbers make accountability harder. Use Creator for teacher-leads or department heads who need to build apps and spin up workspaces, without full org administration. Use Editor for contributors who build apps but don’t run classes. Default new joiners to Viewer or Workspace-only. Upgrade as needed. Walking back access is harder. Review roles every semester. Past staff, departed coaches, and former co-owners often retain access longer than they should.

​
Key points

  • Five org roles cover most needs: Owner, Creator, Editor, Viewer, Workspace-only
  • Owner is the all-access role (and is distinct from a workspace Owner)
  • Roles cascade across all workspaces inside the org
  • Cross-org sharing scopes permissions to the share, not the recipient’s org

​
FAQ

No. An organization Owner has org-wide access — every workspace, app, and setting. A workspace Owner controls a single workspace. The names are the same; the scope is not. Always read “Owner” with its scope in mind.
Owners administer the whole org — members, settings, and visibility into all activity. Creators can build apps, collections, and workspaces, but can’t manage members or see org-wide activity. Editors are a step down from Creators: they build apps and collections but not workspaces.
Not in this release. The five roles cover the most common patterns. Custom role definition is on the roadmap.
When you share an app or Collection with another org, permissions are scoped to that share. The recipient org’s roles do not transfer to your org. Members of the recipient org gain access only at the level you granted in the share.
The role structure is the same. Some orgs sync role changes from their identity provider; others manage roles directly in Playlab. Check with your organization’s Owner.
Yes. From the Members tab, select multiple members with checkboxes and apply a role change to all of them. Useful for end-of-year cleanups.
The apps stay with the original owner. Role changes affect what the member can do going forward. They do not transfer or delete existing apps.
Yes. Each member’s history shows role changes with timestamps and the Owner who made each change.
Yes. Organization Owners can export the audit log from org settings. Useful for compliance reviews.
Last updated: 06-26-2026 Contact us at [email protected]